lambda 


¢ wiki.tcl-lang.org/page/lambda 


Lambda is the name for the letter "L" in the Greek alphabet. Since Alonzo Church's 
Lambda calculus. It is also the term for anonymous functions. 


In Tcl (since 8.5?), a lambda is an anonymous command prefix whose first word is apply. 


The lambda package in Tcllib provides an appropriate implementation, as follows: 
proc lambda {arguments body args} { 


return [list ::apply [list $arguments $body] {*}$args] 
} 


proc lambda@ {ns arguments body args} { 
return [list ::apply [list $arguments $body $ns] {*}$args] 
} 


See Also 
Lambda in Tcl 
lambda in tcl8.5 


Lambda, Why and How 


Lightweight Lambda 
Functions as Values 


ycl sugar lambda 
A slightly more flexible implementation of lambda. Another command named block is the 
same but additionally triggers evaluation. 


Reference 


My Favorite Calculus: Lambda (part 1) , MarkCC, 2006 


The Genius of Alonzo Church: Numbers in Lambda Calculus , MarkCC, 2006-06-15 


Description 

Richard Suchenwirth et al: 
Consider 

f(x) = xt1 


is not much different from 
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g(x) = xt+1 


except for the f/g difference, which are both arbitrary names. The common essence of the 
above functions, ignoring the name, is just 


(x) = x+1 

or in other words, "given x, return x+1". In Tcl, this looks like 

lambda x {expr {$x+1}} 

and it's easy to implement - see Lambda in Tcl and Lambda in Tcl8.5. 
To have lambdas directly, one change to Tcl would be: 


If acommand name is a list of length three, with lambda as first element, bind its 
arguments to the second element of the list, and then evaluate the third element in 
that scope. 


As long as we don't have this, a simple way is to make up a name for a proc: 


proc lambda f{argl body} { 
set name [info level 0] 
proc $name $argl $body 
set name 


} 
where the lambda definition is returned as command name. 
A more functional programming way would be, using the K combinator: 


proc lambda f{argl body} {K [info level ©] [proc [info level 0] $argl $body]} 
proc K {a b} {set a} 


See also RPN again for "half-lambdas": only the body is the value of a function, 
arguments are popped from the stack, the result is pushed on the stack. 


MS 2004-04-23: Although not really functional programming, one might try to do 
lambda x {set ::y x} 


But this fails: Tcl tries to create a proc named y x} in the namespace lambda x {set ", 
instead of the intended proc. This may be a namespace bug though. 


It seems like it would be pretty easy for unknown to do this automatically... 


RS: Yes. Good idea. Let unknown know. It would just miss the efficiency of C-coded Tcl, 
but with today's CPUs, that's less of a problem... 2005-03-29: Here's the unknown code, 
leading to pure-value lightweight lambdas (see Block-local variables for how it came 
about): 
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proc with f{argl body args} f{ 
if {[llength $argl] != [llength $args]} {error "wrong #args, must be: $argl"} 
foreach $argl $args {} 
eval $body 

} 


#-- Augmenting [unknown]: 
proc know what {proc unknown args $what\n[info body unknown] } 
know { 
if {[llength [lindex $args 0]] > 1} { 
return [uplevel 1 [lindex $args 0] [lrange $args 1 end]]} 


} 


#-- Testing (the lambda is just a string that we assign to a variable): 
% set tail {with x {lrange $x 1 end}} 

with x {lrange $x 1 end} 

% $tail {a b cd e} 

bcde 


RS: While the term /Jambda was coined by Alonzo Church, the concept is older. | found 
one instance in "Funktion und Begriff", Gottlob Frege (1848-1925), Jena 1891, where he 
identifies functions by their Werteverlauf (value extension?), without naming them. 
Instead, he first puts a Greek vowel with "spiritus lenis" (looking like a superscript comma 
on top of the letter), and then the function "body" in parens. He then goes to show 
(translated to modern ASCII, and even (almost) Tcl :) that 


lambda e {expr $e**2 - 4*$e} == lambda a {expr $a * ($a - 4)} 


In other words, that the two anonymous functions are identical. To prove this, one would 
have to iterate over all possible values of e and a (which, even with doubles, is finite, but 
might take a long time...) 


NEM 2010-07-02: Re-reading Norvig's classic Paradigms of Artificial Intelligence 
Programming just now, | came across this explanation for the origins of the term "lambda 


(§1.7): 


"Lambda derives from the notation in Russell and Whitehead's Principia Mathematica, 
which uses a caret over bound variables: x(x+x) [*]. Church wanted a one-dimensional 
string, so he moved the caret in front: “x(x+x). The caret looked funny with nothing below 
it, so Church switched to the closest thing, an uppercase lambda, Ax(x+x). The A was 
easily confused with other symbols, so eventually the lowercase lambda was substituted: 
Ax(x+x). John McCarthy was a student of Church's at Princeton, so when McCarthy 
invented Lisp in 1958, he adopted the lambda notation. There were no Greek letters on 
the keypunches of that era, so McCarthy used (lambda (x) (+ x x)), and it has survived to 
this day." 


[*] There's a “ over the first x, but your browser might not display it correctly. 
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Since I've done my share of LISP programming in the past, the term lambda is instantly 
recognizable to me. I'm not convinced it means much to the average programmer, 
though. Given RS's description at the start of this page f(x) = x+1 ... in other words, given 
x, return x+1 ..., it makes me think that perhaps "given" would make a more readable / 
recognizable name for a command than "lambda". 


For example, instead of this: 


lambda x {expr {$x+1}} 


... perhaps the following makes a more readable example, especially when used with an 
explicit return... 


given {x} {return [expr {$x + 1}]} 


Using "given" and an explicit return, | bet even folks who have never heard of "lambda" 
can understand what is going on. RS: | know that not everyone agrees, but when doing 
functional programming an implicit return should be no surprise... :*) 


LV: | don't understand the use of the word given in this situation. 


coward: it is just a more human-friendly form of the word "lambda". It means "make an 
anonymous proc with the arguments {x} and the body {return ...} 


LV: Also, why use expr instead of incr? 

coward: 

RS: expr still works if x is a floating-point number, while incr demands an integer. 
Here's more examples (based on examples from lambda in tcl8.5) 

lsort -command [given {x y} { 


return [expr {[string length $x] < [string length $y]}]}] $list 
trace add variable ::foo write [given args {puts "foo = $::foo"}] 


glennj: In lambda... again , comp.lang.tcl, 2007-10-22, Neil Madden wrote in clt an 
excellent summary of the sorts of places lambdas are useful. 


For example, did you realise that apply works nicely with pretty much every command in 
the Tcl and Tk libraries that takes a callback? 
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# I always recommend using a constructor for lambdas: 
proc lambda {params body} { 
list apply [list $params $body] 


} 

lsort -command [lambda {a b} { ... }] $xs 

http::geturl $url -command [lambda tok { ... }] 

after 1000 [lambda {} { puts Hello! }] 

socket -server [lambda {sock addr port} { ... }] 8080 
trace add variable foo write [lambda {v1 v2 op} { ... }] 
etc etc 


ND: lambda proc from nest package 
proc lambda {params body args} { 


set {llength_params} [llength ${params}] 
set {llength_args} [llength ${args}] 


if { ${llength_params} - 1 <= ${llength_args} } { 
set {last_param} [lindex ${params} {end}] 
if { ${llength_params} == ${llength_args} || ${last_param} eq {args} } 


unset {llength_params} {llength_args} 
return [uplevel © ${body} [if {${params} eq {}} { 
# llength_params == 0 and llength_args == 0 
unset {last_param} {params} {body} {args} 
} elseif { ${last_param} ne {args} } { 
# llength_params == llength_args 
lassign ${args} {*}[concat ${params} \ 
[unset {last_param} {params} {body} {args}]] 
} else { 
# (llength_params - 1 <= llength_args) and last_param eq 
{args} 
set {args} [lassign ${args} {*}[lrange [concat ${params} \ 
[unset {last_param} {params} {body} {args}]] 0 f{end-1}]] 
set {} {} 
#1] 


} 


if { ${args} eq {} } { 
return [list {lambda} ${params} ${body}] 
} elseif {${llength_params} >= ${llength_args}} { 
return \ 
[list {lambda} [lrange ${params} ${llength_args} {end}] \ 
[concat \ 
[list lassign ${args} \ 
{*}[lrange ${params} © [expr {${llength_args} - 1}]]] 
a: 
${body}]] 
} else { 
error "lambda: more args than params" 


} 
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apply 


¢ wiki.tcl-lang.org/page/apply 


apply , a built-in Tcl command introduced in version 8.5 , applies a value as a routine, 
passing to it any provided arguments. 


See Also 
proc 


uplevel 


If we had no proc 


Documentation 


official reference 


Synopsis 


apply routine ?arg1 arg2 ...? 


Description 


routine is a list that matches this description: 
args body ?namespace? 


apply applies the routine in the given namespace, passing any additional arguments as 
arguments to that routine. If no namspace is provided the global namespace is used. 


In contrast with proc, apply does not require that the routine be named or that it be 
located in a particular namespace. Since routine is a value, it can be stored in a variable 
and/or passed as a word in another command. 


Examples 


KPV: I've always found the "basic" example with namespaces, etc. too complicated. 
Here's my bare-bones sample code: 


# Simple example: first argument is a duple of argument list and command to apply, 
remaining arguments get assigned to the variable list 
apply {{vari var2 var3} 

{puts "inside a lambda with vari: $vari var2: $var2 var3: $var3"} 

}XYZ 


A basic example: 
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namespace eval nsi { 
variable vari 1 
variable var2 2 


namespace eval ns2 { 
variable vari 3 
variable var2 4 


apply {{x args} { 
foreach arg $args { 
lappend vals [set [namespace current]::$arg] 
} 
:itcl::mathop::+ $x {*}$vals 
} nsi} 3 vari var2 
# -> 6 


apply {{x args} { 
foreach arg $args { 
lappend vals [set [namespace current]::$arg] 
} 
:itcl::mathop::+ $x {*}$vals 
} ns2} 3 vari var2 
# -> 10 


proc map {lambda list} { 
set result {} 
foreach item $list { 
lappend result [apply $lambda $item] 
bi 
return $result 
} 
map {x {return [string length $x]:$x}} {a bb ccc dddd} 
> 1:a 2:bb 3:ccc 4:dddd 
map {x {expr {$x**2 + 3*$x - 2}}} {-4 -3 -2 -101 2 3 4} 
> 2 -2 -4 -4 -2 2 8 16 26 


Implementations for 8.4 and before 


see TIP 194 , which also gives an illustrative implementation in pure-Tcl. 
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proc apply {fun args} { 
set len [llength $fun] 
if {($len < 2) || (S$len > 3)} { 
error "can't interpret \"$fun\" as anonymous function" 
i 
lassign $fun argList body ns 
set name ::$ns::[getGloballyUniqueName ] 
set bodyo { 
rename [lindex [info level 0] 0] {} 
i: 
proc $name $argList ${body0}$body 
set code [catch {uplevel 1 $name $args} res opt] 
return -options $opt $res 


} 
RS wonders, however, how the following simpler take is insufficient: 


proc nsapply {fun args} { 
foreach {argl body ns} $fun break 
namespace eval $ns [list foreach $argl $args break] 
namespace eval $ns $body 


} 


A footnote to this: the above code messes so hard with wish's namespace eval handling 


that it needs to be shut down with Task Manager (Tcl/Tk 8.6.1 on Windows 7). It does 
work in tclsh. 


Testing: 


% nsapply {x {expr $x*$x}} 5 

25 

% nsapply {{x y} {expr hypot($x,$y)} foo} 3 4 
5.0 


NEM: The difference is that in your version parameters are persistent namespace 
variables, rather than local to the procedure. Consider: 


% interp alias {} test1 {} nsapply {x {expr {$x * $x}}} 

testi 

% interp alias {} test2 {} nsapply {x {set y [testi 12]; return $x}} 
test2 

% test2 "Hello!" 

12 


Which isn't what you want, | expect. 


RS: Indeed. In fact, | didn't want namespaces at all :) - just because the other version had 


them... | started with this: 


proc apply {fun args} { 
foreach {argl body} $fun break 
foreach $argl $args break 
eval $body 
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Bryan Oakley: | don't like the syntax. Why is the function itself a list? What is wrong with a 
syntax that lets me use it like this: 


button .b -command [apply arglist body argi arg2 ...] 


... If you need a namespace it could be: 


button .b -command [apply arglist body -namespace foo arg1 arg2] 


... and if you want "-namespace" to not be treated as part of the apply command but 
rather one of the extra arguments you could do: 


button .b -command [apply arglist body -- -namespace foo argi arg2] 


with "{}" and double quoter) Miguel Sofer, 2006-03-29, that structure is required in order 
to be able to cache a bytecompiled body and avoid recompilation at each step. The 
anonymous function carries all the info necessary for compilation {argList body 
namespace} in a single Tcl_ Obj. 


Note also that this makes it easier to have 


set anon [list argList body] 
button .b -command [list apply $anon arg1 arg2] 
button .b1 -command [list apply $anon arg3 arg4] 


and have both buttons share the anonymous function - including the bytecompiled 
structures. 


NEM: It's also pretty easy to create a constructor function (which apply is not): 


proc func {params body args} { 

set ns [uplevel 1 namespace current] 

linsert $args © ::apply [list $params $body $ns] 
} 
button .b -command [func arglist body argi arg2 ...] 
# etc... 


| personally use a constructor proc that snapshots the lexical closure into a dict: 
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proc func args { 
set ns [uplevel 1 namespace current ] 
set env [uplevel 1 capture] 
set params [linsert [lrange $args © end-1] 0 _env_] 
set body [list dict with __env__ [lindex $args end]] 
return [list ::apply [list $params $body $ns] $env] 
} 
proc capture {} { 
set env [dict create] 
foreach name [uplevel 1 info locals] { 
upvar 1 $name var 
catch {dict set env $name $var} ;# no arrays 


} 


return $env 


Which | can then use like: 


proc person {name age} {func key {set $key}} 
proc ask {object args} {uplevel 1 $o0bject $args} 
set neil [person {Neil Madden} 25] 

puts "Neil's age is [ask $neil age]" 


I've also on occasion used a further variation that wraps the body in a call to expr. I'll 
leave -namespace as an exercise for the reader. 


Also, in the days before Tcl 8.5: 


What: apply 


Where: http://www.glinx.com/%7Ehclsmith/plugin.html ??? 

Description: Version of the apply procedure as discussed on 
news:comp.lang.tcl during February, 1997. 
Versions of Tcl C and scripting routines as well as a 
lisp-backquote-like proc are available. Now supports Tcl 8.x. 

Updated: 09/1999 

Contact: mailto: [email protected] (Hume Smith) 


NEM wonders if the c.I.t discussion mentioned is Feature request: 'apply' command , 


comp.lang.tcl, 1997-01-26. If so, then the apply mentioned there seems more related to 
{*} than to our current apply command. Or perhaps a version of this: 


proc old-apply {cmd args} { uplevel 1 $cmd $args } 


HD: The Tcl 8.5 man page has this example: 
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proc map {lambda list} f{ 
set result {} 
foreach item $list { 
lappend result [apply $lambda $item] 
} 


return $result 


} 


# Returns {1:a 2:bb 3:cc 4:dddd} 
map {x {return [string length $x]:$x}} {a bb ccc dddd} 


This strikes me as really bad style: it means that map can only be used with "lambdas"; 
you can't use normal commands unless you cast them as lambdas. So what would be 
better? 


It is already common style to pass command prefixes as callbacks. "The cmd argument is 
a command prefix to which two additional arguments will be added..." Suppose we wrote 
map like this instead: 


proc map {prefix list} { 
set result {} 
foreach item $list { 
lappend result [{*}$prefix $item] 
7 


return $result 


} 
Then we can write 


# Returns {1:a 2:bb 3:cc 4:dddd} 
map {apply {x {return [string length $x]:$x}}} {a bb ccc dddd} 


But we can also write 


# Returns {1 2 3 4} 
map {string length} {a bb cc dddd} 


An apply expression then becomes just another kind of command prefix. 


NEM: This is indeed good style, as is always using a constructor function rather than a 
literal: 


proc lambda {params body args} { 
set ns [uplevel 1 namespace current] 
list ::apply [list $params $body $ns] {*}$args 


} 
map [lambda x ...] $xs 


Lars H: The virtue of "constructor function rather than literal" is highly debatable, IMO. 
Capturing the namespace context is good, but since that constructor function recreates 
the lambda Tcl_ Obj every time it is called, the above has the severe drawback that the 
same lambda is going to get recompiled over and over again. A literal lambda persists, so 
it is only compiled once. 
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NEM: What's that phrase about premature optimisation? Byte-code compilation is fast 
and if you are constructing a lambda inside a tight loop then simply move it out. Not 
properly encapsulating code because of some weird obsession with eliminating a few 
microseconds is just wrong. 


Lars H: Is this a fear of complex literal data | see? Or just a reaction on having one's style 
put under scrutiny? Claims that one style is "always" good deserve to be critized. The 
"simply move it out" approach hurts other goals for good code, such as keeping related 
things together, so why should one always take precendence over the other? 


As for the "premature optimisation": It's not so much the time for recompilation that 
concerns me (even though this is obviously low-hanging fruit), but rather that the object is 
being created again and again — the use of a constructor function to produce a constant. 
For one, it is tantamount to shimmering, which IMHO is best avoided from the start rather 
than eliminated in a clean-up phase. Second, it can at times (although probably not in this 
case) be a severe memory bloat to recreate a Tcl_Obj rather than sharing one that 
already exists. Sure, the constructor function can use memoizing to counter that, but this 
introduces the problem of life-cycle management, and complicates the code. The literal 
constant is just so much easier! 


The general argument for constructor functions — that less code need to be modified if 
the underlying representation changes — is hardly relevant for apply lambdas, so 
advocating their use here can itself be considered an act of premature optimisation. ;-) 


MS thinks that this is a whole different kettle of fish. Depending on the app, and how 
much memory management may be needed or acceptable, the optimal may be literals 
(live "forever", shared), simple constructor (garbage collected, not shared), memoizing 
constructors (live until explicitly freed, shared), some kind of fancy memoizing 
constructors (could eg free lambdas that were not used in the last X seconds, shared), ... 


WHD: If we had true compile-time macros, a la Lisp or Scheme, could we possibly have it 
both ways? If lambda, as described above, were a macro, you'd only pay the compilation 
penalty once. 


NEM: You don't really need macros. A sufficiently smart byte-compiler could inline the 
lambda constructor into the body it appears in. | doubt very much whether the 
performance gain is at all worth it, though -- we're talking about a constant-time operation 
(assuming the body of the lambda is not changing on each iteration, in which case a 
literal would be no help) that generally takes <10us by my measurements. As Miguel 
points out, what is right for your app might be a trade-off. As Lars even acknowledges, a 
constructor function is free to memoize, effectively transforming itself into the literal 
version. Literals also live forever, so they have no particular advantage over memoizing. 
"Encapsulation is good" is one of the few really solid ideas from software engineering. 
Even for lambdas this encapsulation is a good idea: e.g. you can add enter/exit tracing to 
all lambdas easily, or bundle some extra state, or perhaps wrap the lambda in a coroutine 
or thread so that long-running computations can be transparently handed off without 
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blocking execution. Other advantages are that you avoid many cases of overquoting by 
having implicit list-quoting, avoid ever generating a string rep, can wrap the body in an 
expr or dict with to get custom behaviours, etc, etc, etc. Literals bad functions good! 


RS 2008-10-15: Has it been discussed that apply might also accept command names, i.e. 
non-lambdas? Such that 


apply $f $x $y 

would then work with 

set f {{a b} {expr {sqrt($a*$at+$b* $b) }}} 

as well as 

set f tcl::mathfunc: :hypot 

? - In fact, it's already in recent Tcl sources - dgp pointed me to tclProc.c, search for 
JOE_EXTENSION. 

Combining with [interp alias] 


AMG: [interp alias] and [apply] may be used together as an alternative to [proc]: 


proc name params code 
interp alias {} name apply {params code} 


At first glance, this seems like a waste; just use [proc], right? Yet, consider creating the 
alias in a slave interpreter. Normally it's necessary to create procs in the current 
interpreter to handle aliased commands from slave interpreters, but the procs clutter the 
current interpreter and are callable from the current interpreter despite it sometimes being 
meaningless or dangerous to do so. [apply] bypasses the named proc requirement by 
binding the alias directly to the code, with a parameter list and optional namespace, of 
course. 


set slave [interp create] 
$slave alias add apply {{x y} {expr {$x + $y}}} 
$slave eval {add 2 2} 


Avoid local variable creation 
HaO 2012-07-18: 
apply may also be used to get just a frame for local variables. 


AMG: Put another way, [apply] gives you a temporary scope, after which all local 
variables are cleaned up. 


Example 
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A module is placed in the namespace ns and requires one-time init code. The local 
variables of the init code should not be set as namespace global. 


Solution with global commands 


namespace eval ::ns { 
# Module variable to initialize from some calculations 
variable moduleVar 1 
# Module initialisation 
# variable should be local but is global due to global scope 
set counter 500 
# do some calculation to find initial value 
incr counter $counter 
# and initialize module variable with result 
set moduleVar $counter 
# unset local variable 
unset counter 


Set local variables must be manually unset. 
Solution with one-time init proc 


namespace eval ::ns { 
variable moduleVar 1 
} 
# Module initialisation 
proc ns::init {} { 
variable moduleVar 
# locale variable 
set counter 500 
incr counter $counter 
set moduleVar $counter 
} 
ns::init 
rename ns::init {} 


The init-proc must be manually called and deleted 
Solution with apply 


namespace eval ::ns { 
variable moduleVar 1 


} 
# Module initialisation 
apply {{} { 
variable moduleVar 
set counter 500 
incr counter $counter 
set moduleVar $counter 
} ns} 


Similar to the upper init-proc method but no delete necessary. 
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Default Namespace 


PYK 2014-08-15: What was the rationale for making the default namespace the global 
namespace? My impression is that the vast majority of cases call for apply in the current 
namespace. 


AMG: The anonymous procedure (lambda) needs to be bound somewhere. Even though 
it may seem desirable to behave like [proc] and bind the lambda to the namespace in 
which it was created, this is severely problematic. 


It's hard to precisely define the meaning of "created" since the lambda value can be built 
up in pieces over time by code running in/bound to different namespaces. At what point 
does it become a lambda? The first time it can be parsed as such? The first time it can 
run without error? The first time it gets used as a lambda? That last choice is the Tcl 
answer, but of course the first [apply] can happen very late (if ever), quite possibly long 
after leaving the user-intended namespace. 


This issue doesn't come up with [proc] because procs are indisputably created ata 
specific time and place: whenever/wherever [proc] is invoked. 


In the minds of most users there's a big difference between creation and first use, but due 
to duck typing, the lambda isn't really "created" until used as such. Tcl smooths over the 
difference between user expectation and reality by rendering the difference moot by not 
having anything magical happen at "creation" time. This is the way of values. Procs are 
not values. Lambdas are. 


Pretend that the above problem were solved. How would Tcl keep track of which 
namespace the lambda is bound to? It must be in the string representation itself, or else 
EIAS is violated. But this contradicts the notion of "default" by making it be explicit all the 
time (*). To have it both ways would imply that Tcl automatically adds it to the string 
representation. The last thing we want is for Tcl to "intelligently" rewrite your values 
according to its predictions about how you might end up using them. So no, can't do it 
that way. 


What about having the lambda be bound to whichever namespace [apply] happens to be 
running in? The most obvious problem with this is the lambda would see different 
[variable]s depending on who runs it. This would make lambdas be little more than a 
glorified [eval], rather than a stable, self-contained, reusable unit. 


In conclusion, making the default namespace be :: is the only reasonable approach, all 
other possibilities having been eliminated. 


(*): You can always write a lambda constructor that returns a lambda bound to the current 
namespace, as NEM demonstrates earlier on this page. 


Functional Composition 
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AMG: [apply] is brilliant for building up behaviors, even complex behaviors, from mixed- 
and-matched functional components. 


proc pipeline {args} { 
set lambda {return -level 0} 
foreach arg $args { 
set lambda [list apply [dict get { 
toupper {{lambda input} {string toupper [{*}$lambda $input]}} 
tolower {{lambda input} {string tolower [{*}$lambda $input]}} 
totitle {{lambda input} {string totitle [{*}$lambda $input]}} 
prefix {{lambda pre input} {string cat $pre [{*}$lambda $input] }} 
suffix {{lambda suf input} {string cat [{*}$lambda $input] $suf}} 
} [lindex $arg 0]] $lambda {*}[lrange $arg 1 end]] 
} 


return $lambda 


} 

set command [pipeline toupper {suffix " world"} {prefix "xxx "}] 

chan puts [{*}$command hello] 

chan puts [{*}[pipeline toupper {suffix " world"} prefix] "xxx " hello] 


This prints: 


Xxx HELLO world 
Xxx HELLO world 


Recursive Invocation 


AMG: Normal commands can call themselves without difficulty since they are named 
entities. For [apply], magic is required since lambdas are anonymous. One option is to 
store the lambda in a variable then pass it to the lambda so it can reference itself, but this 
barely counts since the "lambda" is given a name (albeit a scoped name, so this is still 
more flexible than procs). Instead, you can use {*}[lrange [info level 0] 0 1] in place of the 
command name. [info level 0] evaluates to the current command (apply) and its 
arguments, the first of which is the lambda. Alternately, use apply [lindex [info level 0] 1], 
which will have the same effect. 


Here's a command that embeds a recursive helper lambda: 
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proc gsort {list} { 
apply {{a b} { 
if {$a < $b} f{ 
upvar 1 list list 
set p [lindex $list [expr {($a + $b) / 2}]] 
set i $a 
set j $b 
while {1} { 
while {[lindex $list $i] < $p} {incr i} 
while {[lindex $list $j] > $p} {incr j -1} 
if {$i < $j} { 
set swap [lindex $list $i] 
lset list $i [lindex $list $j] 
lset list $j $swap 
incr i 
incr j -1 
} else { 
{*}[lrange [info level 0] 0 1] $a $j 
{*}[lrange [info level 0] 0 1] [expr {$j + 1}] $b 
return 


} 


} 
}} © [expr {[llength $list] - 1}] 
return $list 
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